1. Field of the Invention
The present invention generally relates to server applications and more particularly to HTTP-servlet based applications for resource-constrained devices.
2. Description of the Related Art
Smart cards and other resource-constrained devices provide various services for users via small, easily portable devices. For example, a user inserts a smart card 100 into a card acceptance device 120 such as a bank terminal, which in turn communicates with a remote device 130 that is running a remote application 131. The user completes a banking transaction via smart card 100 and bank terminal 120, removes smart card 100 from bank terminal 120, and retains smart card 100 for future transactions.
To provide a variety of services via smart card 100, smart card 100 typically supports multiple on-card applications, of which banking application 110 is one example. On-card applications generally refer to applications executed on the smart card. On-card applications not only execute on the smart card, but also can interact with one another to provide various services. In some cases, the on-card applications further interact with off-card applications. Off-card applications generally refer to applications executing on a device other than smart card 100.
To provide on-card applications, developers build and test programs using standard software development tools and environments and convert the programs into a form that is installed on smart card 100. For example, Java Card™ technology enables programs written in the Java™ programming language to be installed and executed on a variety of smart cards and other resource-constrained devices. (Java™ and Java Card™ are trademarks of Sun Microsystems, Inc., of Santa Clara, Calif., U.S.)
To protect the services enabled by smart cards, the programs and operations underlying the transactions have associated security mechanisms such as firewalls that prevent one on-card application from accessing information in a context of another on-card application. Firewalls ensure that one application cannot access the data or code of another application unless that application has provided an interface for access, such as a shareable object interface.
The limited resources available on smart card 100 cannot support more generalized approaches for communications between each of the multiple applications or some subset of the multiple applications typically found on smart card 100. Also, in view of the limited resources available, authentication of each off-card client and/or each on-card application service is problematic.
Security of the operations underlying the services also raises issues. In the example of FIG. 1, a proxy 121 is used on-card acceptance device 120 because one communication protocol is used to communicate between remote application 131 and proxy 121 and a different communication protocol is used to communicate between proxy 121 and on-card application 110, sometimes referred to simply as application 110.
Since an end-to-end communication path, i.e., a direct path between remote application 131 and application 110 cannot be established, proxy 121 must decrypt any encrypted information from remote application 131 and re-encrypt the information for transmission to application 110. Similarly, encrypted information from application 110 must be decrypted by proxy 121 and re-encrypted for transmission to remote application 131. This means that there is the potential for sensitive information to be accessible, e.g., in the open, on-card acceptance device 120, which is a significant security issue.
Various security mechanisms are sometimes employed in an attempt to address this security issue. One example is hypertext transfer protocol over Secure Sockets Layer (HTTPS). HTTPS is a scheme that uses the hypertext transfer protocol (HTTP) requests and the additional security measures of the Secure Sockets Layer (SSL) protocol. SSL provides communication endpoint authentication and communication privacy between the server and its clients using cryptography.
Unfortunately, HTTPS is typically used for server authentication to the clients of the server—the clients typically remain unauthenticated. Thus, when a smart card functions as a server, HTTPS provides generic authentication at the server level, i.e., the card application container level.
However, smart card 100 typically includes multiple applications. The applications may be deployed onto the card from different issuers. Each issuer typically requires a level of security specific to the associated application. Further, each issuer determines a set of trusted client applications with which the associated application is authorized to communicate.
Thus, generic authentication of a client application at the card level or the container level is not sufficient, i.e., authentication by the resource-constrained device or by a container managing multiple applications on the resource-constrained device is not sufficient. Each client application must be authenticated at the application level, i.e., verification of authorization for each client application to communicate with the targeted on-card application.
In addition to the foregoing issues, virtual hosting that is utilized with Web-servers presents another issue if it is attempted to extend virtual hosting to smart card 100. Virtual hosting generally refers to the practice of maintaining more than one virtual host, or website, on a single device. Each virtual host is associated with a collection of server applications deployed on that Web-server. Security mechanisms such as HTTPS are sometimes used for client authentication by the virtual host, i.e., each virtual host authenticates each client application with which it communicates.
In cases of client authentication on a per-virtual host basis, however, a virtual host must be manually configured for each server application deployed, resulting in cumbersome efforts with respect to smart card 100. Further, to communicate via the virtual hosts, each client must know the specific port, the domain name, or the IP address of the virtual host associated with the targeted server application. All of these issues make the use of virtual hosts problematic on smart card 100.
In view of the multitude of clients potentially communicating with multiple server applications of various virtual hosts, HTTPS communications quickly become difficult to implement as a comprehensive security solution. As can be seen, the foregoing issues render the implementation of secure transactions and communications associated with a resource-constrained device cumbersome and inflexible.